Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
2/4 - Add new chainsync package
This adds a new
chainsync
package that receives new latest-block updates froman Ethereum JSON RPC server and backtracks a locally cached chain-segment of
previous blocks in comparison with the updated header information. It does this
in order to recognize reorgs and being able to invalidate all chain-state that
was inserted for a reorged-away chain-segment. The information of the difference
of old chain and new chain in case of reorgs is omitted by Ethereum JSON RPC
servers, since it is possible that only the new latest header is received by the
client, and intermediary sections of the new reorg chain are not passively
received. Therefore the client itself has to keep track of the most recent chain
and what gaps between the last common block of a potential new chain segment and
it's old chain-state's segment have to be filled.
In addition to this active syncing mechanism, the
chainsync
package providesan easy way to register handler implementations that retrieve specific
contract-event updates for the newly received chain-segments and the context of
newly "reorged away" chain-segments are available in the same handler. That way,
each handler can define behavior on how to remove old state-updates due to newly
removed events and how to insert new state updates due to newly emitted events.
There is also the possibility to define and execute "chain-update" handler.
Those will not only receive updates for when the newly synced to chain-segment
contains a certain contract event, but they will be executed for every new chain
update and will provide the same chain-update context as the contract-event
handler.